Decode meshopt in buffer structure #160
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
I cleaned up and documented the When applying it (as part of the |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Addresses CesiumGS/3d-tiles-validator#323 :
The
BinaryBufferDataResolveris a convenience class that was supposed to offer a simple functionality:buffer[]/bufferView[]JSON definitionsbuffersData[]/bufferViewsData[](NodeJS-Buffer) objects with the binary dataThis was used for resolving the
buffer/bufferViewstructure within glTF, but also within binary.subtreefiles.The linked issue brought up the case where glTF data uses the
EXT_meshopt_compressionextension. In this case, obtaining the NodeJS-Bufferobjects for a given buffer view is not trivial. First of all, the meshopt-compressed data has to be decoded. Additionally, there may be so-called "fallback" buffers in this structure, which are buffers that do not have auri.This PR extends this class to handle
EXT_meshopt_compression. I'm not perfectly happy with that. This was supposed to be a somewhat "agnostic" class that is now tied to glTF. And ... the handling does not make sense for subtree data (unless... we allowEXT_meshopt_compressionfor.subtreedata...).But given the intended usage (and expectations about convenience that users might have when using this class on glTF
buffer/bufferViewstructures), it may be reasonable to add this here.I'll do further tests (and add specs), so that this may become part of a release soon, so that we can update the validator.